home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 1689 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.2 KB
  1. Path: EU.net!sun4nl!ittpub!ittpub!nntp
  2. Newsgroups: comp.lang.c++
  3. Subject: Re: locking
  4. Message-ID: <1996Jan12.104534.1741@ittpub>
  5. From: wil@ittpub.nl (Wil Evers)
  6. Date: 12 Jan 96 10:45:33 WET
  7. References: <4d1kl2$64c@daphne.ecmwf.int>
  8. Distribution: world
  9. Nntp-Posting-Host: lintilla
  10.  
  11. In article <4d1kl2$64c@daphne.ecmwf.int> mab@ecmwf.co.uk (Baudouin Raoult)  
  12. writes:
  13. > [stuff deleted]
  14. > 
  15. > : For the class
  16. > 
  17. > :     struct Foo { void bar(); }
  18. > 
  19. > : a method-invocation like: 
  20. > 
  21. > :     Foo f;
  22. > :     SharedObject<Foo> s(&f);
  23. > :     s->bar(); // (1)
  24. > 
  25. > : results in 
  26. > :         
  27. > :       ((s.operator->()).operator->())->bar(); // = (1)
  28. > 
  29. > : IMHO, the 'LockObject' temporary created in this expression should be
  30. > : destroyed after this line. To force this behavior from an unwilling
  31. > : compiler (;-) one can put (1) in brackets. So the brackets are used to
  32. > : restrict the lifetime of the temporary and not the one of the
  33. > : SharedObject instance.
  34. > 
  35. > :     Enno
  36. > 
  37. > Thanks for showing some nterest to my original posting. I was
  38. > trying to establish a way to wrap/lock any object and them forget about
  39. > it. So the { } are not a satisfactory. It looks like my  compiler
  40. > (cfront 3.??) is not right.
  41. > 
  42. > Baudouin
  43. >
  44.  
  45. Careful here! The question boils down to the lifetime of a temporary, in  
  46. this case the LockObject. When is it destructed? There are differences  
  47. between compilers currently in use: some compilers destruct the temporary  
  48. at the end of the block in which it was created (in which case Enno's  
  49. bracket trick will restrict the lifetime of the lock), but others may  
  50. destruct the temporary right after the call to its operator->(), in which  
  51. case the lock is released *before* the `bar()' member function is invoked.  
  52. I think the draft standard says the temporary will be destructed at the  
  53. `end of the full expression' (that is, an expression that is not part of  
  54. some other expression), so Baudoin Raoult's trick should work, but not all  
  55. compilers are up to date yet.
  56.  
  57. All in all, it is currently impossible to rely on the lifetime of  
  58. temporary if you want to write portable code. I would go for an explictly  
  59. declared instance of the locking object instead - which unfortunately  
  60. requires extra coding and/or interface replication.
  61.  
  62. - Wil
  63.